Skip to content

Conversation

GeorgeTsagk
Copy link
Member

@GeorgeTsagk GeorgeTsagk commented Jul 31, 2025

Description

With the introduction of multi-rfq send we added a new response item in the send payment stream which includes all of the acquired quotes in an array.

This PR updates the RPC client that handles the stream in the context of litcli to correctly read & parse all the possible response items.

@GeorgeTsagk GeorgeTsagk self-assigned this Jul 31, 2025
Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary of Changes

Hello @GeorgeTsagk, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request primarily focuses on enhancing the litcli command-line interface to fully support the recently introduced multi-RFQ send functionality. It ensures that the client can correctly interpret and present all relevant quote information received during a payment stream, improving the user experience for asset transfers.

Highlights

  • Multi-RFQ Send Support: I've updated the litcli RPC client to correctly parse and display multiple accepted RFQ (Request for Quote) sell orders received in a stream, aligning with the new multi-RFQ send feature in taproot-assets.
  • Stream Processing Refinement: The Recv method within resultStreamWrapper has been refactored to continuously read from the payment stream, handling both individual AcceptedSellOrder messages (for backward compatibility) and the new AcceptedSellOrders array, until the final PaymentResult is received.
  • Flag Usage Clarification: The usage description for the rfq_peer_pubkey command-line flag has been updated to clarify that it is now truly optional, and if unset, RFQ peers will be automatically selected.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in issue comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates litcli to handle multiple RFQ quotes from the payment stream. The main change is in the Recv function, which now loops to process different response types, including a new one for a list of quotes.

My review focuses on two points in the new implementation:

  1. A critical regression that could lead to a panic due to a missing check. I've provided a suggestion to fix this.
  2. A potential for duplicate output due to the logic for handling legacy and new quote messages. I've explained the issue and suggested a more robust pattern.

Overall, the change correctly addresses the need to handle multiple quotes, but the identified issues should be addressed to ensure correctness and robustness.

@GeorgeTsagk GeorgeTsagk added the no-changelog This PR is does not require a release notes entry label Sep 29, 2025
@GeorgeTsagk
Copy link
Member Author

Rebased

@lightninglabs-deploy
Copy link

@GeorgeTsagk, remember to re-request review from reviewers when ready

Copy link
Contributor

@ViktorT-11 ViktorT-11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code generally locks good 🚀! Though I lack quite a bit of context to fully understand this change, so generally just reviewing from a code perspective.

Leaving a few questions that could or could not be helpful.
Other then the suggestions above, I think it would also be helpful for reviewers if you add more details to the commit message description.

Comment on lines +213 to +214
"quote when converting from assets to sats; if left " +
"unset then rfq peers will be picked automatically",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm not seeing that the rest of the changes in this PR actually changes this? If this is due to some other change that's already been merged previously, consider splitting this change into a separate commit and explain why this is now added.

Comment on lines +280 to +304
case *tchrpc.SendPaymentResponse_AcceptedSellOrder:
err := printQuote(r.AcceptedSellOrder)
if err != nil {
return nil, err
}

return resp.GetPaymentResult(), nil
legacyFirstPrint = true

case *tchrpc.SendPaymentResponse_PaymentResult:
return r.PaymentResult, nil
case *tchrpc.SendPaymentResponse_AcceptedSellOrders:
quotes := r.AcceptedSellOrders.AcceptedSellOrders

default:
return nil, fmt.Errorf("unexpected response type: %T", r)
for _, quote := range quotes {
// If the first item was returned via the legacy
// field then skip printing it again here. This
// skip only applies to the first element.
if legacyFirstPrint {
legacyFirstPrint = false
continue
}

err := printQuote(quote)
if err != nil {
return nil, err
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking that this is correct behaviour:
There is no return statement for the *tchrpc.SendPaymentResponse_AcceptedSellOrder & *tchrpc.SendPaymentResponse_AcceptedSellOrders cases here unless there's no error, meaning that they won't break the for loop without any errors being thrown somewhere in the next loop iteration. Is that correct behaviour?

@ViktorT-11
Copy link
Contributor

Also, this would need release notes updates, whenever this gets merged to master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-changelog This PR is does not require a release notes entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants